The present invention relates to methods for arbitrating read and write commands asserted to a DRAM and systems for performing such arbitration. More specifically, the invention relates to methods for arbitrating read and write commands asserted to a DRAM so as to reduce or minimize DRAM performance penalties resulting from transitions between read and write commands, and systems for performing such arbitration.
Modern dynamic random access memories (xe2x80x9cDRAMsxe2x80x9d), including single data rate (xe2x80x9cSDRxe2x80x9d) DRAMS, double data rate (xe2x80x9cDDRxe2x80x9d) DRAMs, and RAMBUS DRAMs, are internally pipelined and often use either a pair of unidirectional data busses or a bidirectional data bus to transfer data during read operations (in which data are read from the DRAM over the bus) or write operations (in which data are written to the DRAM over the bus). The internal pipelining often imposes a performance loss when the DRAM transitions from a sequence of write operations to a sequence of read operations, or vice-versa. When a bidirectional data bus is used, a turnaround time penalty associated with this bus must be incurred to implement each transition from a read operation to a write operation, or from a write operation to a read operation. During each such transition, the bus must be tri-stated for a clock cycle while the previous driver of the data pins becomes tri-stated and the current driver of the data pins is enabled. This is a cycle in which no data may be transferred to or from the DRAM, and thus results in performance loss.
Conventionally, state machines inside a DRAM manage the addresses asserted to the DRAM""s cell array during both reads and writes, the data read out of the cell array during each read operation, and the data written into the cell array during each write operation. When the cell array has been placed in a read state (a state in which it can execute a read command), a finite amount of time (a nonzero performance penalty) is required to place the cell array in a write state (a state in which it can execute a write command). When the cell array has been placed in a read state, it can execute a sequence of read commands without incurring such a performance penalty. Similarly, when the cell array has been placed in a write state, a finite amount of time (a nonzero performance penalty) is required to place the cell array in a read state. When the cell array has been placed in a write state, it can execute a sequence of write commands without incurring such a performance penalty.
A typical use for a DRAM is in a system that includes an arbiter and two or more client devices (xe2x80x9cclientsxe2x80x9d) that assert read and write commands (for the DRAM) to the arbiter. The arbiter is coupled between the clients and the DRAM and configured to apply one or more rules to determine which of contemporaneously asserted commands it will pass through to the DRAM.
We shall use the expression xe2x80x9cread clientxe2x80x9d to denote a client whose most recently asserted command (to an arbiter) is a read command for a DRAM, the expression xe2x80x9cwrite clientxe2x80x9d to denote a client whose most recently asserted command (to an arbiter) is a write command for a DRAM, the expression xe2x80x9ccurrent clientxe2x80x9d to denote the client whose command was most recently passed through to a DRAM by an arbiter, and the expression xe2x80x9ccurrent commandxe2x80x9d to denote the command most recently passed through to a DRAM by an arbiter.
We shall use the expression xe2x80x9cset of commandsxe2x80x9d (and variations thereon) to denote one or more commands contemporaneously asserted to an arbiter, where each command in the set is asserted by a client. We shall use the expression xe2x80x9cset of competing clientsxe2x80x9d (and variations thereon) to denote one or more clients that contemporaneously assert commands to an arbiter, where each client in the set asserts one command to the arbiter.
In order to reduce performance penalties associated with read-to-write or write-to-read transitions, it has been proposed that an arbiter (in a system of the above-mentioned type) be configured to recognize whether the current command is a read command or a write command (and thus to recognize whether the current client is a read client or a write client), and to choose the next client (whose command will be passed through to the DRAM by the arbiter) to be of the same read/write type as the current client. When two or more competing clients are of the same read/write type as the current client, the arbiter uses another criterion (or other criteria) to select the next client from among these competing clients. However, the arbiter cannot select (as the next client) a matching client (having the same read/write type as the current client) from among multiple clients (competing to be selected as the next client) when none of the competing clients is of the same read/write type as the current client. To select one of multiple competing clients as the next client (when none of them is of the same read/write type as the current client), conventional arbiters apply some other rule (or rule set) to select the next client as rapidly as is practical (and without delay).
However, the present inventors have recognized that DRAM systems (that include conventionally implemented arbiters of the described type) are subject to significant limitations. For example, they are incapable of significantly reducing performance penalties associated with read-to-write or write-to-read transitions when responding to many sequences of competing commands (e.g., a repeating sequence of multiple competing read commands followed by multiple competing write commands).
In a class of embodiments, the invention is a system including at least one DRAM, an arbiter coupled to the DRAM, and at least two clients coupled to assert read and write commands (for the DRAM) to the arbiter. The arbiter is operable to select among competing ones of the clients (by determining which one of contemporaneously asserted commands from the clients to pass through to the DRAM). When arbitrating among competing clients that include at least one client of the same read/write type as the current client, the arbiter selects (as the next client) one of the competing clients that is of the same read/write type as the current client. When arbitrating among a set of clients that includes no client of the same read/write type as the current client, the arbiter operates in a wait mode during a predetermined wait interval by selecting (as the next client) a client (if any) that asserts a command of the same read/write type as the current command. After the wait interval, the arbiter enters another arbitration mode in which a command of the opposite read/write type can be chosen. For example, if a first set of clients competes for access to the DRAM at a first time during the wait interval but none of these clients is selected during the wait interval, the arbiter applies a rule set (comprising at least one rule) to select as the next client one of a second set of the clients that are competing for access to the DRAM at a second time after the wait interval. The second set of competing clients can be identical to the first set of competing clients, or it can consist of the first set of competing clients and additional clients. Typically, the rule set requires that, if at least one of the clients in the second set is of the same read/write type as the current client, the arbiter selects as the next client one of the clients in the second set that is of the same read/write type as the current client, and that otherwise the arbiter selects as the next client one of the clients in the second set that is of the opposite read/write type as the current client. Typically, the wait interval is a predetermined, small number of clock cycles.
Other aspects of the invention are an arbiter for use in any embodiment of the inventive system, and a method for arbitrating among commands asserted by clients for access to a DRAM at a time when a current client has been selected. The method includes the steps of:
in response to a set of competing ones of the clients that includes at least one client of the same read/write type as the current client, selecting (as the next client) one of the clients in the set that is of the same read/write type as the current client; and
in response to a set of competing ones of the clients that does not include any client of the same read/write type as the current client, operating in a wait mode during a wait interval having a predetermined duration and commencing at a first time, by selecting (as the next client) a client (if any) that asserts a command of the same read/write type as that of the current client, and at a second time after the wait interval, entering another arbitration mode in which a command of the opposite read/write type can be accepted. For example, at the second time (after the wait interval), if no command of the same read/write type as that of the current client has been asserted during the wait interval, a rule set (comprising at least one rule) can be applied to select as the next client one of a second set of the clients that are competing for access to the DRAM at said second time. Typically, the wait interval is a predetermined, small number of clock cycles.
In accordance with the invention, an arbiter operates with the goal of granting DRAM access requests from clients such that the resulting sequence of granted requests (and the corresponding sequence of read and/or write commands passed through by the arbiter to the DRAM) contains a minimum of xe2x80x9cread to writexe2x80x9d and xe2x80x9cwrite to readxe2x80x9d crossovers in order to minimize performance penalties associated with such crossovers. Granted read requests and write requests are grouped with their own kind as much as possible. Rather than selecting the next client from a set of competing clients whose read/write type does not match that of the current client (a set of xe2x80x9cnon-matchingxe2x80x9d clients), the arbiter waits for at least a predetermined time (e.g., a predetermined number of clock cycles) before granting an access request of the wrong type (one that would result in a xe2x80x9cread to writexe2x80x9d or xe2x80x9cwrite to readxe2x80x9d crossover). This allows time for a client whose read/write type matches that of the current client (a xe2x80x9cmatchingxe2x80x9d client) to become active and be selected immediately, thus avoiding a read/write turnaround penalty that would otherwise be incurred.
If the predetermined wait time is too long, the DRAM may be inactive for an undesirably long time if no matching client becomes active soon after the start of the wait period. This can result in a performance penalty greater than the read/write turnaround penalty. If the predetermined wait time is not long enough, an opportunity can be missed in which a matching client becomes active just after (e.g., on the next clock after) the wait interval ends and a non-matching client is selected as the next client (resulting in a read/write turnaround penalty). For these reasons, the predetermined wait time is preferably equal (or substantially equal) to the system""s xe2x80x9cread to writexe2x80x9d transition performance penalty or xe2x80x9cwrite to readxe2x80x9d transition performance penalty (e.g., the predetermined wait time is the system""s xe2x80x9cread to writexe2x80x9d transition performance penalty when the current command is a read command, and the predetermined wait time is the system""s xe2x80x9cwrite to readxe2x80x9d transition performance penalty when the current command is a write command). In embodiments that employ the preferred wait time, when the wait time has expired, the choice between an access request of a matching type and an access request of a mismatching type will be performance neutral. Typically, a xe2x80x9cread to writexe2x80x9d or xe2x80x9cwrite to readxe2x80x9d crossover is allowed immediately after expiration of a wait period, but not during the wait period (to limit the frequency at which crossovers can occur).
In some preferred embodiments, the arbiter of the invention is programmable or otherwise implemented to be operable in any of multiple operating modes. For example, it can have separately programmable wait times for xe2x80x9cread to writexe2x80x9d and xe2x80x9cwrite to readxe2x80x9d situations. For another example, the arbiter operates in a conventional manner (i.e., with the predetermined xe2x80x9cwait timexe2x80x9d equal to zero) before the first xe2x80x9cread to writexe2x80x9d or xe2x80x9cwrite to readxe2x80x9d transition (the first xe2x80x9ccrossoverxe2x80x9d) in the sequence of xe2x80x9ccurrent clients,xe2x80x9d and after the first crossover the arbiter operates in accordance with the invention. For another example, the arbiter operates in a xe2x80x9cpre-waitxe2x80x9d mode in a conventional manner (i.e., with predetermined xe2x80x9cwait timexe2x80x9d equal to zero) before the first crossover in the sequence of xe2x80x9ccurrent clients,xe2x80x9d then (after the first crossover) operates in a xe2x80x9cwaitxe2x80x9d mode in accordance with the invention (with nonzero wait time) for a predetermined time interval, then (after the predetermined time interval) operates in a xe2x80x9cpost-waitxe2x80x9d mode in a conventional manner (with zero wait time) until the next crossover in the sequence of current clients, then operates again in the xe2x80x9cpre-waitxe2x80x9d mode, and so on in a repeating sequence of operating modes. Variations on the exemplary operating mode sequences are contemplated.